再談了一些跟檔案系統的效能與設計相關的主題如LVM、磁碟系統等等之後，本周開始要進入檔案系統的正題。或許還有許多牽涉到檔案系統的背景知識還沒說仔細，如RAID架構、LVM運作的細節等等(或許有哪些是我沒想到的)，有機會的時候我們會再把他補齊的。今天我就從專題設計出發，談談製作"檔案系統" 有哪些需求。
再談了一些跟檔案系統的效能與設計相關的主題如LVM、磁碟系統等等之後，本周開始要進入檔案系統的正題。或許還有許多牽涉到檔案系統的背景知識還沒說仔細，如RAID架構、LVM運作的細節等等(或許有哪些是我沒想到的)，有機會的時候我們會再把他補齊的。今天我就從專題設計出發，談談製作"檔案系統" 有哪些需求。

事實上，設計檔案系統並沒有標準解答，端看需求而定。還記得我們在"磁碟系統的運作" 這篇提到，如果你的檔案永遠都小於等於磁碟上一個 sector的大小(512KB)，那麼你的檔案系統將是非常簡單，只要記錄每個檔案所在的sector即可，一個蘿蔔一個坑，用一個表格就可以實作完成。但是往往事情沒這麼單純，因為絕大部份的檔案大小都是不定的，所以無法只佔用一個sector，既然需要跨越多個sector，所以檔案系統就必須去維護這些屬於同一個檔案的sector的關係。維護檔案的內容、存取位址，讓他在讀寫的過程中不致損壞或失去功能，就是檔案系統的基本需求。

需求不同，檔案系統的設計導向就不同。譬如在XBOX 360(要舉Wii或是PS3也行啦)中的磁碟，需要何者檔案系統呢? 由於遊戲主機中就不需要進階的搜尋功能，但是特別強調檔案的有效性，就算突然關閉、reset主機，資料仍舊有保障。所以在遊戲主機中的檔案系統或許就要犧牲一點點效能，製作日誌功能**(Journaling)**，以換取存取保證。

除了應用需求之外，儲存媒體也是一大重點，循序存取的磁帶跟隨機存取的磁碟，絕對需要不同的檔案系統。相容性也是一大考量，特別是行動裝置上的儲存媒體像是Flash卡、應用在相機、手機上時，往往有跨平台存取的需求。